A destination object can be either a queue or topic, which are software components (applications) structured to encapsulate address syntax for a specific provider. A distributed destination is a set of destinations (queues or topics) that are accessible as a single, logical destination to a client and can have the following characteristics:                It is referenced by its own Java Naming and Directory Interface (JNDI) name, which is part of the Java platform, providing applications based on Java technology with a unified interface to multiple naming and directory services.        Members of the set are usually distributed across multiple servers within a cluster, with each destination member belonging to a separate server, which for a non-limiting example, can be a Java Messaging Service (JMS) server.        
Distributed destinations provide customers with higher availability and greater scalability for applications such as JMS queues and topics than simple destinations because they can provide load balancing and failover for member destinations of a distributed destination within a cluster. Once properly configured, your producers and consumers are able to send and receive messages through the distributed destination. A Web or JMS server then balances the messaging load across all available members of the distributed destination. When one member destination becomes unavailable due to a server failure, traffic is then redirected toward other available destination members in the set.
Heterogeneous distributed destinations, however, can be harder to configure and maintain than necessary. In order to create a distributed destination, the administrator or application packager needs to manually create and configure physical destinations first before they can function as members of the distributed destination. Although his approach provides the flexibility to create individual members that are intended to carry extra message load or have extra capacity and with a load balancing policy that matches the capacity, such differences often lead to administrative and application problems because such a weighted distributed destination was not deployed consistently across a cluster. Furthermore, certain properties of the member destinations must be made uniform in order to function properly. For a non-limiting example, if there are two members which have different security restrictions, the same user may connect to the same destination twice and once be allowed to send messages while another time be forbidden to do so.